REMARKS/ARGUMENTS 

Claims 23-44 are pending herein. Claims 1-22 have been cancelled in favor of 
new claims 23-44, which correspond to original claims 1-22, but correct matters of 
form and more distinctly point out and claim the present invention. Applicant 
respectfully submits that no new matter has been added. 

1. The objections to the drawings in paragraph 1 of the Office Action are noted, 
but deemed moot in view of the submission of replacement drawing sheets submitted 
herewith as Appendix C. 

2. The objections to the drawings in paragraphs 2 and 3 of the Office Action are 
noted, but deemed moot in view of the amendments to the specification at page 19, 
line 3 to amend an incorrect reference and at page 40 lines 1 9-20 to amend the text in 
accordance with Figure 20 filed herewith. 

3. The objection to the specification in paragraph 4 of the Office Action is noted, 
but deemed moot in view of the amendment to the specification at page 40 lines 19-20 
filed herewith. 

4. Claims 1-22 were rejected under §112 second paragraph as being indefinite. 
As previously stated, Applicant has cancelled claims 1-22 in favor of new claims 23- 
44, which correspond to original claims 1-22, but correct matters of form and more 
distinctly point out and claim the present invention. To the extent that this rejection 
may be applied against the new claims, it is respectfully traversed. 

With respect to claim 1, the Examiner's assertion that the phrase "the read-out 
quality information" lacks antecedent basis in paragraph 8 of the Office Action is 
noted but deemed moot in view of the cancellation of claim 1 . Claim 23, which 
replaces claim 1 , does not contain the aforementioned term. Accordingly, Applicant 
respectfully requests that the Examiner reconsider and withdraw this rejection. 
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With respect to claims 7 and 18, the Examiner's assertion concerning the claim 
limitation recited in paragraph 9 of the Office Action is noted but deemed moot in 
view of the cancellation of claims 7 and 18. Claims 29 and 40, which replace claims 7 
and 18, respectively, do not contain the phrasing the Examiner asserted was not 
understandable. The meaning of the language in question can be found in the 
specification at page 24. Based on the above, Applicant respectfully requests that the 
Examiner reconsider and withdraw this rejection. 

5. Claims 12-22 were rejected under §101 for being directed to non- statutory 
subject matter as detailed on pages 5-8 of the Office Action. As previously stated, 
Applicant has cancelled claims 1-22 in favor of new claims 23-44, which correspond 
to original claims 1-22, but correct matters of form and more distinctly point out and 
claim the present invention. To the extent that this rejection may be applied against 
the new claims 34-44, it is respectfully traversed. 

The Examiner asserted that claims 12-22 only recite an abstract idea 1 and do 
not produce a useful, concrete and tangible result as required by § 101 . In accordance 
with MPEP §2106, patentable subject matter - computer-related inventions, states that 
computer related processes are limited to a practical application in the technological 
arts and what is determinative is not how the computer performs the process, but what 
the computer does to achieve a practical application. See Arrhythmia Research Tech. 
v. Corazonix Corp. 958 F.2d 1053, 1057, 22 USPQ2d 1033, 1036 (Fed. Cir. 1992) 
(MPEP §2106 at pages 2100-17-18). Here, the claimed processes are limited to a 
practical application, namely, providing statistical support data relating to the sale 
price and time required to sell similar transaction target articles in the same price 
range and other price ranges. The data input into the claimed processes includes 
numeric data, such as selling price of similar transaction target articles of similar 
quality and length of time a transaction target article was advertised before sale, as 



1 Office Action at page 6. 

2 Office Action at page 8. 
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well as non-numeric data, such as answers to assessment questions and quality 
evaluating information. Applicant asserts that this transformation and manipulation of 
numeric and non-numeric data into statistical support data provides buyers and sellers 
of transaction target articles information in a form that is tangible and very useful. 

Further, Applicant disagree with the Examiner's assertion that the claimed 
processes "do not apply, involve, use, or advance the technological arts since all the 
recited steps can be performed in the mind of a user or by use of pencil and paper" 
(Office Action at page 6). Here, the recited processes receive a limited input set of 
data from the requestor and make an initial determination whether to process the input 
data based on the quality of the transaction target article (i.e., using period). If the 
using period has not been exceeded, the processes then attempt to locate transaction 
achievement information for the same transaction target article of similar quality. 
Where transaction achievement information is located, the processes read the 
transaction achievement information, manipulate/convert non-numeric data into a 
numeric value or representation, compute and transmit one or more of the statistical 
support data items for a transaction target article to the requestor, as described in the 
application. The data output from the price setting support processes provides 
statistics, which enable the requestor to determine whether the initial selling price is 
optimal based on financial or other external considerations. The aforementioned 
processes at a minimum use the technological arts since data is evaluated, 
manipulated/converted and transformed into an output that is useful, as admitted by 
the Examiner. In addition, the recited processes are limited to a practical application 
and are, therefore, statutory subject matter. Accordingly, Applicant respectfully 
requests the Examiner reconsider and withdraw this rejection. 
6. Claims 1-7, 9, 12-18 and 20 were rejected under § 102(b) over Walker. The 
rejection is noted but deemed moot in view of Applicants cancellation of claims 1-22 
in favor of new claims 23-44, which correspond to original claims 1-22, but correct 
matters of form and more distinctly point out and claim the present invention. To the 
extent that this rejection may be applied against new claims 23-29, 32, 34-40 and 42, it 



Page 15 of 20 



is respectfully traversed. In general, Walker discloses a system and method for 
determining a posting payment amount (Col. 2, lines 42-43). With respect to claims 1 
and 12 (new claims 23 and 34), the Examiner's cited reference in Walker at Col. 5, 
lines 27 and 32-36, discusses "receiving" information, but does not address "receiving 
identifying information and quality evaluating information." Similarly, the 
Examiner's cite to Col. 5, lines 1, 22, discusses making an item that is for sale known 
by displaying the item on a buyer's computer display, but does not teach or suggest 
transmitting to a requestor the quality information for the transaction target article. In 
view of the above, Applicant respectfully submits that Walker does not teach each and 
every element recited in the amended claims. Accordingly, Applicant respectfully 
requests that the above rejection be reconsidered and withdrawn. 

With respect to claims 2 and 13 (new claims 24 and 35), the Examiner's cited 
reference at Col. 5, lines 23-25 discloses that the memory units and/or the storage 
device may store instructions adapted to be executed by the processor. However, the 
cited reference neither teaches nor suggests a statistic value calculating unit that 
calculates a statistical value for transaction price of a transaction target article where at 
least one transaction achievement information is located and read. In addition, the 
Examiner's cite to Col. 5, lines 1, 22, does not teach or suggest transmitting to a 
requestor the calculated statistic value for the transaction target article, for the reason 
discussed under claims 23 and 34. In addition, claims 24 and 35 depend from claims 
23 and 34, respectively, and claims 23 and 34 define patentable subject matter for the 
reasons explained above. In view of the above, Applicant respectfully submits that 
Walker does not teach each and every element recited in the amended claims. 
Accordingly, Applicant respectfully requests that the above rejection be reconsidered 
and withdrawn. 

With respect to claims 3 and 14 (new claims 25 and 36), the Examiner's cited 
reference to FIG. 4 shows a tabular representation of a portion of the item database. 
This reference cite neither teaches or suggests a statistic value calculating unit that 
calculates a statistic value of the necessary time for a transaction to be completed 
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where at least one transaction achievement information is located and read. In 
addition, the Examiner's cite to Col. 5, lines 1 5 22, does not teach or suggest 
transmitting to a requestor the statistic value of the necessary time together with the 
statistic value of the transaction price for the transaction target article, for the reason 
discussed under claims 23 and 34. In addition, claims 25 and 36 depend from claims 
23 and 34, respectively, and claims 23 and 34 define patentable subject matter for the 
reasons explained above. In view of the above, Applicant respectfully submits that 
Walker does not teach each and every element recited in the amended claims. 
Accordingly, Applicant respectfully requests that the above rejection be reconsidered 
and withdrawn. 

With respect to claims 4 and 15 (new claims 26 and 37), the Examiner's cited 
reference to Col. 7, lines 4-7 discloses that the posting system can examine past posts 
for the same class and type of item. Additionally, in text not cited, Walker discloses 
that the posting system may estimate the value of an item. However, this neither 
teaches nor suggests an extraction unit extracting transaction achievement information 
based on the desired price and quality evaluating information input by the seller. 
Further, the Examiner's cite to Col. 5, lines 1, 22, does not teach or suggest 
transmitting to a requestor the statistic value of the necessary time based on the 
extracted item of transaction achievement information for the transaction target article, 
for the reason discussed under claims 23 and 34. In addition, claims 26 and 37 depend 
from claims 23 and 34, respectively, and claims 23 and 34 define patentable subject 
matter for the reasons explained above. In view of the above, Applicant respectfully 
submits that Walker does not teach each and every element recited in the amended 
claims. Accordingly, Applicant respectfully requests that the above rejection be 
reconsidered and withdrawn. 

With respect to claims 5 and 16 (new claims 27 and 38), the Examiner's cited 
reference to FIG. 8 discloses a tabular representation illustrating a relationship 
between floor prices, previous posting information and posting payment amounts. 
FIG 8 data is limited to percentage of items that sold with a particular floor price. 
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However, this neither teaches nor suggests a statistic value calculating unit that 
calculates a statistic value of the transaction price and a statistic value of the necessary 
time in each of a plurality of price ranges. Additionally, the Examiner's cite to Col. 5, 
lines 1, 22, does not teach or suggest transmitting to a requestor the statistics of the 
transaction prices and the necessary time corresponding to each of the price ranges for 
the transaction target article, for the reason discussed under claims 23 and 34. In 
addition, claims 27 and 38 depend from claims 23 and 34, respectively, and claims 23 
and 34 define patentable subject matter for the reasons explained above. In view of 
the above, Applicant respectfully submits that Walker does not teach each and every 
element recited in the amended claims. Accordingly, Applicant respectfully requests 
that the above rejection be reconsidered and withdrawn. 

With respect to claims 6 and 17 (new claims 28 and 39), the Examiner's cited 
reference to FIG 4, which shows a tabular representation of a portion of the item 
database, as previously discussed, fails to teach or suggest calculating a statistic value 
of the transaction price and a statistic value of the necessary time in each of a plurality 
of advertising periods set for the transaction target article. Additionally, the 
Examiner's cite to Col. 5, lines 1, 22, does not teach or suggest transmitting to a 
requestor the calculations of the transaction prices and the necessary time 
corresponding to each of the advertising periods for the transaction target article, for 
the reason discussed under claims 23 and 34. In addition, claims 28 and 39 depend 
from claims 23 and 34, respectively, and claims 23 and 34 define patentable subject 
matter for the reasons explained above. In view of the above, Applicant respectfully 
submits that Walker does not teach each and every element recited in the amended 
claims. Accordingly, Applicant respectfully requests that the above rejection be 
reconsidered and withdrawn. 

With respect to claims 7 and 18 (new claims 29 and 40), the Examiner's cited 
reference to FIG 6A, which discloses a tabular representation of a condition item sheet 
and pricing table. FIG 6A and the associated text fail to teach or suggest basing 
quality information on the seller's using period and dividing the seller's using period 
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into a plurality of time periods that correspond to the condition of a transaction target 
article. In addition, claims 29 and 40 depend from claims 23 and 34, respectively, and 
claims 23 and 34 define patentable subject matter for the reasons explained above. In 
view of the above, Applicant respectfully submits that Walker does not teach each and 
every element recited in the amended claims. Accordingly, Applicant respectfully 
requests that the above rejection be reconsidered and withdrawn. 

With respect to claims 9 and 20, (new claims 31 and 42), the Examiner's cited 
reference to Col. 6, lines 23-27 discusses transmitting a blank Condition of Item Sheet, 
which may ask the seller the condition of the item being sold or what peripherals are 
included with the item. The cited reference does not teach or suggest employing an 
assessment ranking in which the assessment score is incremented or decremented 
based on the seller's answer. In addition, claims 31 and 42 depend from claims 23 and 
34, respectively, and claims 23 and 34 define patentable subject matter for the reasons 
explained above. In view of the above, Applicant respectfully submits that Walker 
does not teach each and every element recited in the amended claims. Accordingly, 
Applicant respectfully requests that the above rejection be reconsidered and 
withdrawn. 

Claims 8 and 19 (new claims 30 and 41) were rejected under 103(a) over the 
Examiner taking official notice that no one would purchase a component that has 
exceeded its useable life span. This rejection is noted but deemed moot in view of 
Applicant's cancellation of claims 1-22 and submission of replacement claims 23-44, 
which amend original claims 1-22 to better conform to U.S. practice. To the extent 
that this rejection may be applied against new claims 30 and 41, it is respectfully 
traversed. Dependent claims 30 and 41 depend from claims 23 and 34, respectively, 
and claims 23 and 34 define patentable subject matter for the reasons explained above. 
Accordingly, Applicant respectfully requests that the above rejection be reconsidered 
and withdrawn. 

Claims 10 and 21 (new claims 32 and 43) were rejected under § 103(a) over 
Walker and claims 1 1 and 22 (new claims 33 and 44) were rejected over Walker in 



Page 19 of 20 



view of Cherington. These rejections are noted but deemed moot in view of 
Applicant's cancellation of claims 1-22 and submission of replacement claims 23-44, 
which amend original claims 1-22 to better conform to U.S. practice. To the extent 
that this rejection may be applied against new claims 32, 33, 43 and 44, it is 
respectfully traversed. Dependent claims 32, 33, 43 and 44 depend from claims 23 
and 34, respectively, and claims 23 and 34 define patentable subject matter for the 
reasons explained above. Accordingly, Applicant respectfully requests that the above 
rejection be reconsidered and withdrawn. 

If the Examiner believes that contact with Applicant's attorney would be 
advantageous toward the disposition of this case, the Examiner is herein requested to 
call Applicant's attorney at the phone number noted below. 

The Commissioner is hereby authorized to charge any additional fees 
associated with this communication or credit any overpayment to Deposit Account No. 



50-1446. 



Respectfully submitted, 



February 9, 2006 
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Amendments to the Drawings : 

Attached hereto as Appendix C are 7 pages of replacement drawing sheets 
including changes to Figs. 2, 3, 4, 12, 19, 20 and 22. Also attached hereto as 
Appendix D are 7 pages of Annotated Drawing sheets showing the changes made to 
Figs. 2, 3, 4, 12, 19, 20 and 22 marked in red. 

Attachment: Appendix C - replacement drawing sheets 
Appendix D - annotated drawing sheets 
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SUPPORT SYSTEM FOR SETTING PRICE OF TRANSACTION TARGET ARTICLE 

BACKGROUND OF THE INVENTION 
1. Field of the Invention 
5 The present invention relates generally to a support system 

for setting a price of a transaction target article, and more 
particularly to a transaction target article price setting 
support system applicable to a computer network based transaction 
system. 

10 2. Description of the Prior Art 

With a spread of the Internet over the recent years, the 
commercial transactions are daily conducted via the Internet. 

A conventional transaction information system for providing 
services for the commercial transactions via the Internet, 
15 especially a used article transaction information system, 
includes a sales bulletin board (electronic bulletin board 
system) on which a sales price of a transaction target article 
is put up, an auction system in which a participant who sets 
the highest price for the auction article makes a successful 
20 bid of this article, and so on. 

In the Internet-based commercial transactions described 
above, the users of the Internet are allowed to put up sales 
target articles on the sales bulletin board and participate in 
the commercial transactions as sales applicants such as entering 
25 the articles in the auction. 

According to the used article transaction information 
system, the sales applicant puts up his or her own 

VERSION WITH MARKINGS TO SHOW CHANGES MADE 
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unncccooary transact ion target article on the sales bulletin 
board or enters it in the auction. In this case, the sales 
applicant is able to set a price effor the transaction target 
article (a minimum price in the auction) as the applicant desires . 
5 On the occasion of setting the price by the sales applicant, 
however, the conventional transaction information system 
provides none of no information for setting the price. 

A great majority of the sales applicants are, however, 
amateurs about with respect to how to sell the articles offered, 

10 and know nothing about the current market prices on the market 
of the Qalca for sale of the transaction target uocd article. 
The sales applicant therefore tends to set the price higher than 
the market price, with the result that tfeea purchaser can not 
be found out , or by contraot conversely , sets the price lower 

15 than the market price, with the result that the sales applicant 
becomes aware of having made an unprofitable transaction after 
the dcalinga sale . 

SUMAMRY OF THE INVENTION 

20 it is a primary object of the present invention to provide 

a support system for setting a price of a transaction target 
article, by which a sales applicant is able to set a proper price 
of the transaction target article. 

To accomplish the above object, according to one 

25 aspect of the present invention, a support system for setting 
a price e#for a transaction target article in response toarequest 
given from a rcqucatcr , comprises a storage unit storing 
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identifying information for identifying the transaction target 
article and quality information for indicating a t he quality of 
the transaction target article, a receiving unit receiving the 
identifying information of the transaction target article of and 
5 the quality evaluating information for evaluating a quality of 
the transaction target article for which a price should be set 
by the requester-? — and quality evaluating information for 
evaluating a quality of the transaction target article , a reading 
unit reading the quality information coincident with the received 

10 identifying information and quality evaluating information, and 
a transmitting unit for transmitting the read out assessed 
quality information to the requester. 

According to the present invention, the quality 
information is transmitted to the requester as the support 

15 information for setting the price, and hence the price can be 
set with the quality information being used as a key factor . 

The above support system according to the present invention 
may further comprise a transaction achievement information 
storage module for storing completed transaction (achievement^ 

20 information containing information on a transaction price e# 
a tranoQction inf ormation for transactions actually 
conductcd completed with respect to the transaction article, and 
a statistic value calculating unit for calculating— when the 
reading unit reads from the transaction achievement information 

25 storage module at least one item of transaction achievement 
information coincident with the inputted identifying 
information and the read out quality information, a statistic 
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value of the tranoaction price contained in at loaat one item 
of tranoaction information that hao been read out , a statistic 
value for the transaction price when at least one transaction 
achievement information coincident with the input identifying 
5 information and quality information is read-out from the 

transaction achievement information storage module, and the 
transmitting unit may transmit the calculated statistic value 
of the transact ion price . The statistic value is, for example, 
an average value of the transaction price . Thus, the statistic 

10 value of the transaction price based on transaction achievements 
is transmitted as the support information to the requester, and 
therefore the requester is able to set the price more properly. 

The support system according to the present invention may 
further comprise a necessary time related information storage 

15 module storing information on athe necessary time for the a 
transaction to actually conducted be completed with respect to 
the transaction target article. The statistic value 
calculating unit may calculate a statistic value of the necessary 
time on the basis of a single item or plural items of transaction 

20 achievement information read out , and the transmitting unit may 
transmit, to the requester, the statist ic value of the necessary 
time together with the statistic value of the transaction price . 
The statistic value is, for instance, an average value of the 
necessary time. 

25 The support system for setting the price of the transaction 

target article according to the present invention is capable 
of supplying the requester with the quality information and the 
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statistic value serving as a-key factors in for setting the price, 
whereby the sales applicant bocomca is able to set the proper 
price of the transaction target article. 

5 BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 io a diagram showing FIG. 1A and IB are high-level 
diagrams of a network architecture of a transaction system in 
a fione embodiment of the present invention; 

FIG. 2 is a diagram showing an example of a hardwaro an 
10 example of a hardware architecture for the server and client 
in one embodiment of the present invention architecture of the 
transaction system ; 

FIG. 3 is a server process flowchart showing processes 
of a ocrvcr of the first embodiment of the present invention (sheet 

II; 

FIG. 4 is a server process flowchart showing processes 
of the server (sheet 2) ; 

FIG. 5 is a diagram showing a an example of an input display 
example on an input screen ; 

FIG . 6 is a diagram showing an example of a vehicle component 
database ; 

FIG. 7 is a diagram showing an example of a transaction 
history database; 

FIG. 8 is a diagram showing an example of a price range 

table; 

FIG. 9 is a diagram showing an example of a message of support 
■ information displayed in a client to a sales applicant 
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corresponding to process step S13 ; 

FIG. 10 is an explanatory diagram ohowing example of a first 
collection table; 

FIG. 11 is a diagram ohowing an example of a message o# 
5 the oupport — information displayed in the clicnt to a sales 
applicant corresponding to process steps S15 and S16 ; 

FIG. 12 is an explanatory diagram ahowing example of a 
second collection table; 

FIG. 13 is a diagram ohowing an example of a message e# 
10 the oupport information displayed in the clicnt to a sales 
applicant corresponding to process steps S18 and S19 ; 

FIG. 14 is a diagram ohowing an example of an input screen 
in a second embodiment; 

FIG. 15 is a diagram ahowing an example of an assessment 
15 item database; 

FIG. 16 is a diagram ahowing a diopiay an example of a second 
input screen; 

FIG. 17 is an explanatory diagram ohowing an example of 
an assessment rank table; 
20 FIG. 18 is a diagram ohowing an example of a message e# 

the oupport information displayed in the clicnt to a sales 
applicant ; 

FIG. 19 is a server process flowchart showing an operation 
of the server in the second embodiment (sheet 1) ; 
25 FIG . 2 0 is a server process flowchart showing the operation 

of the server in the second embodiment (sheet 2) ; 

FIG. 21 is a diagram ohowing a diopiay an example on thc of 
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an input screen in a third embodiment; 

FIG. 22 is an explanatory diagram ohowing example of a 
vehicle database; and 

FIG. 23 is an explanatory diagram ohowing example of a 
maintenance/repair history database . 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Embodiments of the present invention will hereinafter be 
discussed with reference to the accompanying drawings. The 
present invention is not, however, limited to the following 
embodiments . 

[First Embodiment] 

To begin with, a first embodiment of the present invention 
will be explained. 

<Network Architecture > 

FIG. 1A is a high-level diagram showing an example of a 
network system architecture e #f or a transaction gyatcm to which 
a— support system for setting a price of a transaction target 
article , io applied . FIG. IB is a high-level interface diagram 
of a bulletin board in one embodiment of the present 
invent ion ohowing a principle of the tranoaction gyatcm 

Referring to FIGS. 1A and IB, the transaction system is 
configured by to operate on a server S as the transaction target 
article price setting support system, and the server S connects 
to a plurality of clients C^as request source parties^ connected 
via an Internet N to the oerver C . A topology in The methods 
by which the clients C and the server S are connected to the 
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Internet N, may takc include any one of the existing connection 
modes (such as a dial-up access, an ISDN connection and a leased 
circuit connection) . 

The server S functions as a World Wide Web (WWW) server 
5 and retains information on a Web site (homepage) including that 
includes a bulletin board 1 for browsing piccca of sales 
information of articles for sale . The server S provides the 
client C with access to the Web site^ including the bulletin 
board 1^ in response to a client C request given from each client 

10 G. Each client C functions as a WWW browser, and a user e#at 
the client C is able to browse the bulletin board 1 provided 
f rom by the server S. The bulletin board 1 lists up the 
transaction information on the sale articles dealt with which 
are referred to as transaction targcts target articles , and the 

15 article information for each transaction target article is 
registered in an unillustrated database of the server S. 

The user_j_ as a sales applicant (seller) of each client 
is allowed to put up enter information efi on the bulletin board 
1 for the article that the user_^ himself or herself^ wishes to 

20 sell-? — on the bulletin board 1 . On the other hand ln addition , 
the uocr, when the gale of thc a transaction target article the 
user^ himself or herself^ wants to gct purchase is put on the 
bulletin board 1, the user is able to show an intention of 
purchasing the article via the bulletin board 1 to the sales 

25 applicant (seller) or otherwise (such as delivering an E-mail 
indicating the intention of buying it to the sales applicant) . 

A sales contract is thcrcby then agreed upon between the 
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seller (the sales applicant) and the purchase applicant, and 
the article is exchanged with f or a value equivalent . A provider 
(administrator) of the Web site including the bulletin board 
1 may be categorized as a broker via the bulletin board 1, who 
5 collects a brokerage fee from the user putting up , e.g., inputting 
the sales information on the bulletin board 1. 

Further, though not shown, the server S provides each 
of the clients C with a virtual auction site as a part of the 
Web site . The user of each client C enters a na transaction target 

10 article the user desires to sell , and ahowo enters a minimum price 
thereof. Then, a user of othcr another client C ahowo enters a 
price of this art iclc the user is willing to pay for the transaction 
target article that is equal to or higher than the minimum price . 
Then, the user ohowing entering the highest price is able to 

15 purchase this transaction target article. 

Thus , according to the Internet Nbased transaction system, 
the users of the clients C are capable of selling and buying 
fefe etransaction target articles via the bulletin board 1 and the 
virtual auction site as well. 

20 In the first embodiment, the server S provides each of 

the clients C with access to the bulletin board 1 for ^e inputt ing 
transaction information (sales information) on vehicle 
components (parts) as transaction targets. The user of the 
client C is either freely able te-or given a permission to pttt 

25 ^a pinput transaction information on the bulletin board 1 for a 
user's own vehicle component (irrespective of whether it is new 
or used one ) that the user desires to sell. The vehicle in- 
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tcrminology components may inc ludc a inc lude a privately owned car , 
a truck, a motor bicycle, etc. 

At this time, the user must indicate a desired sales price 
e #for the vehicle component on the bulletin board 1. On this 
5 occaaion Here , the server S provides the user of the client C 
with information for a upport ing assi sting the user to act in 
setting the desired sales price. 

<Hardware Architectures of Client and Server> 

Next, hardware architectures of each client C and the 

10 server S shown in FIG. 1 will be cxpl a incd de scribed . FIG. 2j_ 
for example, io a diagram ohowing an example of the shows one 
embodiment of a hardware architccturco archi tecture for- e# the 
client C and the server S . In this example, all of the Thc clients 
C have, however, are assumed to have the same architecture, end 

15 therefore^ only one client C is illustrated in FIG. 2. 

Referring to FIG. 2, the server io conatructcd by uoc 
e# for example , comprises a personal computer (PC) , a workstation 
(WS) , a host computer including the above those components, or 
a dedicated server machine etc. 

20 The server S includes a CPU 2 (corresponding to a reading 

unit, a stat istic value calculating unit and an extracting unit ) , 
a main memory (MM) 3, an external storage device (secondary 
storage) 4 (corresponding to a storage unit) , a communication 
interface (corresponding to a communication interface I/F: a 

25 transmitting unit and a receiving unit) 5 connected via a 

communication line to the Internet N, and interface circuits 
(I/F) 6, 7 and 8. 
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A display device 9 such as a cathode-ray tube, a liquid 
crystal display, a plasma display etc is connected to the I/F 
6. A keyboard (KBD) 10 is connected to the I/F 7. A pointing 
device (PD) 11 such as a mouse, a trackball, a joystick, a flat 
point etc is connected to the I/F 8. 

The external storage device 4 io constructed by use 
o# comprises, for example, a readable/writable recording medium 
suchas aharddisk, a floppy disk, an optical disk, a magneto-optic 
disk (MO) etc. thc The external storage device 4 is stored with 
plural kindo of a plurality of programs such as an operating system 
(OS) , a program relative to a communication protocol and a program 
for the server S to function as t-hea WWW server which are all 
executed by the CPU 2 . The external storage device 4 io further 
Qtorcd with also stores data (such as a text file, an image file 
and an HTML (HyperText Markup Language) file that create a 
homepage containing the bulletin board 1. 

Moreover, the external storage device 4— ^stores the 
transaction information the user (sales applicant ) of the client 
C who puto up on input to the bulletin board 1 for the vehicle 
component the user desires to sell, rctaino as well as retaining 
information in the following databases (DBs) for supporting the 
user on setting a component DD 23, a tranoaction history DB 24, 
a price range tabic 25, an assessment item DB 26, an assessment 
ran3c tabic 27, a maintenance/repair hiotory DB 28 and a vehicle 
DB 2 9 ao databases (DBs) for supporting the uocr to act the price 
of the vehicle component : a component DB23, a transact ion history 
DB 24, a price range table 25, an assessment item DB 26, an 
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assessment rank table 27, a maintenance/repair history DB 28 
and a vehicle DB 29 . The external storage device 4 corresponds 
to a storage unit according to the present invention. 

The CPU 2 , corresponding to an input of indication of an 
5 when initialized by an operator of the server S , copies necessary 
items of data programs and data files to main memory 3 from the 
external storage device 4, then loads the necessary 
progra m programs and data files corresponding to the input of 
indication into the MM 3 from the external storage device 4 and 

10 executes the loaded program. The CPU 2 thereby executes 

processes related to communications protocols for establishing 
communications with the client C, e.g., a variety of information 
processes^ such as a proccaa of processes for providing the 
homepage containing the bulletin board 1 in response to a client 

15 C request from the client C , and a process of processes for 
providing support information for oupporting the setting e#-the 
price of thc a vehicle component. 

Namely, the CPU 2 executes the program programs , whereby 
the server S functions as a transaction target article price 

20 setting support system including the storage unit , the receiving 
unit, the reading unit, the transmitting unit, the statistic 
value calculating unit and the extracting unit. 

The main memory (MM) 3 is used as a working area for the 
CPU 2 and also used as a video random access memory (VRAM) for 

25 storing texts, images and videos displayed on a screen of the 
display device 9. 

The client C io constructed by uoing the comprises , for 

VERSION WITH MARKINGS TO SHOW CHANGES MADE 

Appendix B 



example, a personal computer (PC) . All the computers used as 
client C are each capable of becoming at least an information 
processing terminal (DTE: Data Terminal Equipment) to the 
existing Internet N and include devices, such as the workstation 
(WS) , mobile computers, personal digital assistants (PDA) like 
an electronic note etc, a car navigation terminal, a mobile 
telephone (cellular phone) and so on , can be applied to the client 
G . 

The client C includes a CPU 12, a main memory MM 13, an 
external storage device 14, and a communication interface (I/F) 
15, interfaces (I/Fs) 16, 17 and 18 that are the same components 
as I/Fs 9, 10 and 11 those of the server S. A display device 
19 is connected to the I/F 16. A KBD 20 is connected to the 
I/F 17. A PD 21 is connected to the I/F 18. 

The external storage device 14 is stored with a variety 
of programs such as an OS, a program for the client C to function 
as the WWW browser, and a program related to the communication 
protocol with respect to thc protocols for establishing 
communications with server S . 

The CPU 12 , corresponding to an input of indication of when 
utilized by the user (operator) of the client C, copies necessary 
items of data to MM 13 from the external storage device 14, then 
loads the program corresponding to the input of 
indication necessary programs into the MM 13 from the external 
storage device 14 and executes the progra m programs . The CPU 
12 thercby then executes a process effor requesting the server 
S to provide the bulletin board 1, a process e #for transmitting 
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to the server S the information that should be put up on the 
bulletin board 1, and a process eifor requesting the server S 
to provide information for supporting the user to set a price 
of the vehicle component. 
5 <Processes of Server and Client> 

Next, a discussion on the processes of the server S and 
of the client C will be made focusing on the process of the server 
S. The user of the client C, when browsing the bulletin board 

1 retained in the server S, accesses the server S by an operation 
10 ^ on the client C. 

That is, the user booto init ializes the WWW browser hy- 
operating on the client C and_j_ thereafter^ specifies a URL 
(Uniform Resource Locator) linked to the homepage containing 
the bulletin board 1 of the server S. Then, the CPU 12 of the 

15 client C transmits a request for providing to access a Web page 
corresponding to the URL to the Internet N from the communication 
interface I/F 15. This request is received by the server S via 
the Internet N. 

Then, the CPU 2 of the server S starts the server processes 

20 shown in FIG. 3 . FIGS. 3 and 4 are flowcharts ohowing depict ing 
the processes (the processes in the server S) executed by the 
CPU 2 of the server S. Referring to FIG. 3, at step SI the CPU 

2 of the server S is in a otatuo of communicating with and accepting 
a variety of requests from the respective clients C (step SI) . 

25 Thereafter, the CPU 2, when accepting the request given 

from the client C a client C request (step SI; Y) , j udgeo determines 
whether or not the accepted request is a client C request e# 
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the client C for acccoaing to access the bulletin board 1 (which 
is a request for providing the Web page of the bulletin board 
1) (step S2) . 

At thio time , If the CPU 2™ when j udging determines that 
5 the client C request is tfeea request for providing to access the 
bulletin board 1 (step S2 ; Y) , the CPU 2 provides the client 
C with the relevant Web page of the bulletin board 1 (step S3) . 
To be more specific, the CPU 2 reads from the external storage 
device 4 the HTML file, the text file and the image file that 

10 configure the relevant Web page, and transmits these files to 
the requesting client C concerned via the communication I/F 5. 
Thereafter, the CPU 2 returns the processing to step SI and reverts 
to the atatuo of accepting other requests. 

The HTML file and other files transmitted from the server 

15 S are received by the communication interface 15 of the relevant 
client C via the Internet N. Then, the CPU 12 of the client 
C creates, on the MM 13, image data e#for the Web page on which 
the texto and imagco are laid out based on the texts, images 
and descriptions ef-in the received HTML file. The CPU 12 then 

20 displays an image corresponding to the Web page image data on 
the screen of the display device 19. 

The Web page of the bulletin board 1 is thereby displayed 
on the display device 19 of the client C, whcrcby al lowing the 
user of the client C is able to browse the sales information 

25 of the vehicle component put up components for sale on the bulletin 
board 1 . 

Hcrcin Here , it is assumed that the user of the client C 
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tri cs is trying to sell an unncccooary a vehicle component (used 
parts: secondhand parts) fey^utilizing the bulletin board 
ift In this case, the user of the client C must indicate input 
a sales price effor the galea targct vehicle component 
5 (transaction target article ) vehicle component and thus put 
^input the sales information (transact ion information) thereof 
on the bulletin board 1. 

At this time, the user, if unconfident of the sales price 
of the vehicle component and unsure to judge how long it takes 

10 a time to cotabliah will take to complete the transaction, inputs 
an indication a request for being provided with support 
information for setting the sales price by opcrat ing operat ion 
of the KBD 20 and/or the PD 21. Then, the CPU 12 of the client 
C generates a message of the roqucot for providing thc requesting 

15 transaction price setting support information, and delivers the 
message to the server S from the communication interface I/F 
15 via the Internet N. 

The CPU 2 of the server S, when receiving the transaction 
price setting support information providing request received 

20 b yf rom the communication interface 5, makca replies with a "YES" 
j udgemcnt response in step S4 after through if steps SI and S2 
have been completed , and advances the processing to step S6. 
Whereas if Otherwise the CPU 2 makco replies with a "NO" 
j udgemcnt response in step S4 , and the CPU 2 executes other process 

25 corresponding to the request received in step S5, and loops the 
processing back to step SI. 

When the processing proceeds to step S6 , the CPU 2 transmits , 
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to the client C, the data of an input screen 31 for inputting 
the information needed for creating the support information^ 
as shown in Fig, 5 . When the client C receives the data on the 
input screen 31, the CPU 12 displays the input screen 31 on the 
5 display device 19 on the baoio of the oamc data . 

FIG. 5 is a diagram ohowing a diaplay an example of the 
input screen 31 displayed on the display device 19. Referring 
to FIG. 5, the input screen 3 1 includes a component (parts) number 
entry box 3 2 e# f or the vehicle component corresponding to the 
10 oalco transact ion target article , an image displaying area 33 
for displaying the image or video of the vehicle component, a 
using period entry box 34 e# f or the vehicle component, a desired 
sales price entry box 35, and a send button 36. 

The component number entered in the entry box 3 2 involves 
15 the use of, for instance, a number allocated beforehand to the 
component by the provider (administrator) of the Web page of 
the bulletin board 1. The image displaying area 33 displays 
an image of the component scanned by, e.g. , a camera type image 
scanner (not shown) connected via an unillustrated interface 
20 to the client C. In thia caac one configuration , aa-input button 
33a provided on the input screen 31 is used as a start button 
e# f or a scan operation of the image scanner. 

In this respect, when the user of the client C specifies 
a component image file (GIF (Graphics Interchange Format) , 
25 Windows BMP, JPEG (Joint Photographic Experts Group), etc.) 
recorded on the external storage device 4, the component image 
may also be displayed in the display area 33. In this case, 
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the component image file is created from a digital image 
photographed by, e.g. , a digital camera and or a digital video 
camera, and is recorded on the external storage device 4. 

A The time period (using period) for which the user has 
5 been using the vehicle component concerned, is entered^ on g for 
example in monthly unit units in the entry box 34 . The using 
period unit for the using period may be arbitrarily fee-set- — Ato 
a year, date, hour and minute may alao be each adopted as a t he 
unit for the using period . The sales price (desired sales price) 
10 of the vehicle component , which is desired by the user , is entered 
in the entry box 35. 

The user, when the input screen 31 is displayed on the 
display device 19, inputs the component image to the client C 
by manipulating the KBD 2 0 and/or the PD 21, and enters the 
15 component number, the using period and the desired sales price 
in the entry boxes 32, 34 and 35. Thereafter, when depressing 
the send button 3 6^ by manipulating the KBD 2 0 or the PD 21, 
the CPU 12 transmits, to the server S, pieces of the identifying 
information of the vehicle component (the image and the component 
20 number) of the — ( tranaact ion target ) — vehicle component , the 
quality evaluating information (using period) and the desired 
sales price that a^e have been inputted via the input screen 31. 

On the other hand, thc The CPU 2 of the server S, when af ter 
transmitting the data on the input screen 31 to the client C 
25 in step S6, waits for the information inputted via thc completed 
input screen 31 to be transmitted from the client C (step S7) . 
Then, the CPU 2, when af ter receiving the relevant information 
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from the client C (step S7; Y) , advances the processing to step 
S8 . 

In step S8, the CPU 2 rcfcro to accesses the component 
database (DB) 23 stored in the external storage device 4 and 
5 reads, from the component DB 23, a rccord any records 

corresponding to the component number received from the client 
C into the main memory MM 3 , and advances the processing to step 
S9. 

FIG. 6 io a diagram ohowing depict s an example of a data 
10 structure of the component DB 23 shown in FIG. 2. Referring 
to FIG. 6, the component DB 2 3 retains at least one record 
consisting of a component number field, a component code field, 
a standard price field, a field of using condition A, a filed 
of using condition B and a field of using limit (using condition 
15 C) . 

The component number is a unique number allocated to the 
component by the administrator of the Web site including the 
bulletin board 1 , and is used as the identifying information 
(ID) of the component . The component code is a code given assigned 

20 by the administrator based on a function of the vehicle component 
function irrespective of a category of the vehicle, and is used 
as information for ohowing a category of categori zing the 
component. The standard price is a standard retail price (a 
so-called fixed price) of the component . Note that the standard 

25 price may also be a price accounting for a market price such 
as an actual retail price on the market. 

Further, Each of the using conditions A, B and C is defined 
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as quality information indicating a quality corresponding to 
the usingperiodof the vehicle component , and is set per component 
The using limit indicates a using period that has expired when 
e with the value of the component comes to becoming nothing (zero) . 
5 The When the using period exceeds the using limit component e# 
which the uoing period exceeds the using limit is dealt with 
as what io valueless . A record in the component DB 2 3 is created 
each time a transaction target component to be put up article 
is input and registered on the bulletin board 1 is added and 

10 rcgiotcrcd as a for sale item . 

In step S9, the CPU 2 of the server S compares the using 
period received from the client C with the using limit in the 
record read into f rom the MM 3 , and j udgco determines whether the 
using period exceeds the using limit. At this time, — the CPU 

15 2, if lf the using period exceeds the using limit (step S9; Y) j_ 
the CPU 2 advances the processing to step S10 and executes an 
error process . Namely, the CPU 2 creates an error message saying 
that the component the user desires to sell has exceeded its 
using period exceeding the using limit and is valueless 

20 (impossible of being sold) , and delivers this message to the 
client C . The error message is thereby displayed on the display 
device 19 of the client C. Thereafter, when finiahing the CPU 
2 finishes the process in step S10-r the CPU 2 and returns the 
processing to step SI. 

25 By contrast, the CPU 2 , if the using period does not exceed 

the using limit (step S9; N) , the CPU 2 obtains a using condition 
of the component (step Sll) . That is, the CPU 2 compares the 
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using period with each of the using period conditions A, B and 
C in the record, and specifies the using condition coincident 
with the input using period. 

Next, the CPU 2 reads— into the MM 3, all of the records 
5 with the corresponding to the component number received from 
the client and tewith the corresponding using condition obtained 
in step Sll out of the transaction history database (DB) 24 stored 
in the external storage device 4 (step S12; see FIG. -3r4-4_) , and 
advances the processing to step S13 . 

10 FIG. 7 is a diagram ohowing an example of a data structure 

of the transaction history DB 24 shown in FIG. 2. Referring 
to FIG. 7, the transaction history DB 24 is a database stored 
with a history of the tranoaction cotabliahcd t ransact ions 
initiated via the bulletin board 1. The transaction history 

15 DB 24 consists of a single record or a plurality of records each 
composed of fields such as an advertisement number, a transaction 
number, a transaction date , a component number , a component code, 
a using condition, a using period, an advertisement starting 
date, a transaction price and an assessment rank. Each of the 

20 records stored in the transaction history DB 24 corresponds to 
transaction achievement information according to the present 
invention . 

The advertisement number is a unique number used as 
information for specifying the sales information (transaction 
25 information) put up input and displayed (advertised) on the 
bulletin board 1. The transaction number is a unique number 
for specifying the tranoaction cotabliahcd t ransact ions 
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initiated via the bulletin board 1. The transaction date is 
a year, month and date when the tranoaction hao been 
ootabliohod transactions were initiated , and the administrator 
of the bulletin board 1 adequately sets a date when the sales 
5 contract hao been ootabliohcd was adequately completed or a date 
when the vehicle component hao bccn was exchanged with for a value 
equivalent . 

The advertisement starting date is a date when the sales 
information starts being available ( advertised) on the bulletin 

10 board 1. The transaction price is a^ the amount of money set 
as the value equivalent to the component in the sales contract 
o# f or the vehicle component. The assessment rank indicates a 
quality based on a predetermined assessment standard set by the 
administrator of the bulletin board 1 . Note that each time fehea 

15 transaction is cotabliohcd initiated via the bulletin board 1, 
a new record of the sales transaction cotabliohcd initiated is 
registered in the transaction history DB 24 as one of the other 
processes in step S5 . 

In step S13, the CPU 2 obtains an average number of bid 

20 tender days during which bids for the component in a price range 
(price zone) inclusive of the desired sales price have been 
received from the clients C^by^using single record or a plurality 
of records (refer as "first extraction record (s)") read 
o^t extracted from the transaction history DB 24 in step S12 . 

25 The average number of bid tender days is a number of days required 
for cotabliohing initiating the transaction of the transaction 
target componcnt article since the transaction information of 
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the transaction target article was advertised on the bulletin 
board 1, and indicates a rcquircd the period of time required 
for initiating the transaction. The time which the transaction 
hao been cotabliohcd io agreement time may be selected from , for 
5 example, a the time when the purchaser ohowed conveyed an intention 
e#to purchase to the seller, a the time when the intention of 
purchaoc the purchaser was conveyed to the administrator of the 
bullet in board 1, and a on the time when the component was exchanged 
with the value equivalents — may properly be — selected . 

10 To describe step S13 in depth, the CPU 2 rcf era to accesses 

the price range table 2 5 stored in the external storage device 
4, and j udges determines which price range the desired sales price 
falls within in the price range table 25 the dcoircd oalco price 
concerned fallo within . 

15 FIG. 8 is a diagram showing an example of the price range 

table 2 5 shown in FIG. 2. As shown in FIG. 8, tfeea price range 
table 2 5 is provided for every component number in thio example . 
The price range table 2 5 may, however, only be provided for every 
component code . 

20 Further, the price range table 2 5 in this example provides 

five price ranges such as 0 - 5000 yen, 5001 - 8000 yen, 8001 
~ 10000 yen, 10001 ~ 15000 yen and 15001 - 99999 yen. The CPU 
2 compares the desired sales price with each of the price ranges, 
thereby drawing out determining the price range inclusive of the 

25 desired sales price. 

Note that the number of the price ranges and a size of 
each price range may be properly set. Further, as a substitute 
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for using the price range table 25, a minimum price and a maximum 
price that define a price range may also be arithmetically 
calculated to set different price ranges , such as setting a range 
for every 2 000 yen or 3 00 0 yen and so on. 

The CPU 2 , when obtaining Af ter determining the price range 
embracing the desired sales price, the CPU 2 extracts a— 
rccord records in which the transaction prices falls within the 
price range as a second extraction record from a first extraction 
record. Subsequently, the CPU 2 subtracts the advertisement 
starting date from the transaction date with respect to each 
of the second extraction records, and divide a sum of the 
subtracted results by the number of the second extraction records , 
thereby obtaining an average number of bid tender days. 

Thereafter, the CPU 2 creates a message containing the 
using condition obtained in step Sll and the average number of 
bid tender days obtained in step S13, and delivers the created 
message to the relevant client C (step S14) . Thereafter, the 
CPU 2 advances the processing to step S15. 

The client C, — whcn When receiving the message delivered 
from the server S, the client C displays the received message 
on the display device 19 . FIG. 9 is a diagram showing a dioplay an 
example of a message 37 displayed to the sales applicant that 
corresponds to the process in step S13 . Thus, the component 
sales applicant (the user of the client C) is provided with the 
using condition as the quality information of the 
oalcs transaction target component art icle and the average number 
of bid tender days in the price range inclusive of the desired 
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sales price as pieces of support information for setting the 
sales price. 

In step S15, the CPU 2 obtains the average number of bid 
tender days for every price range and subsequently obtains an 
5 average transact ion price for every price range (step S16) . The 
processes in steps S15 and S16 will hereinafter be explained 
in greater dctaila detail . 

The CPU 2 creates a first collection table based on the 
price range table 2 5 referred to in step S13 in the main memory 
10 MM 3. FIG. 10 is an explanatory diagram ahowing example of a 
first collection table 38. The first collection table 38 is 
a table for collecting the number of records, the number of days 
and the transaction price , which corrcopond corresponding to each 
of the price ranges retained in the price range table 25. When 
15 the first collection table 38 is created, the number of records, 
the number of days and the transaction price, which correspond 
to each of the price ranges, are each set to zero as an initial 
value (see FIG. 10) . 

The CPU 2, when creating the first collection table 38, 
20 with respect to a certain first extraction record, refers to 
the price range inclusive of the transaction price thereof, and 
increments [the number of records] in the first collection table 
3 8 by u l" ("1" is added to the number of records) , which 
corrcoponda corresponding to the relevant price range. 
25 Subsequently, the CPU 2 subtracts the advertisement starting 
date from the transaction date in the first extraction record, 
and adds a value of this subtracted result to [the number of 
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days] corresponding to the relevant price range. Further, the 
CPU 2 adds the transaction price in the first extraction record 
to [the price] corresponding to the relevant price range. The 
CPU 2 executes the processes given above with respect to all 
5 the first extraction records. 

Thereafter, the CPU 2, when finishing the above processes 
for all the first extraction records, divides a value of each 
[number of days] and a value of each [price] retained in the 
first collection table 38 by [the number of records] 
10 corresponding thereto. Thus, the CPU 2 obtains an average value 
(an average number of bid tender days) of [the number of days] , 
and also an average value (an average transaction price) of the 
[price] . 

Thereafter, the CPU 2 creates a message containing the 
15 average number of bid tender days and the average transaction 
price that have thus been obtained, and transmits the created 
message to the relevant client C (stepS17) . After this process , 
the CPU 2 advances the processing to step S18 . 

The client C, whcn A fter receiving the message delivered 
20 from the server S, the client C displays this message on the 
display device 19. FIG. 11 is a diagram ohowing a diaplgy an 
example of a message 3 9 to the sales applicant, which 
corrcopondo corresponding to the processes in steps S15 and S16 . 
The user of the client C is thus provided with the using condition 
25 corresponding to the quality information on the oalco transact ion 
target article ( vehicle component^ as the support information 
for setting the sales price. The user of the client C is also 
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provided with the average number of bid tender days and the average 
transaction price for every price range. 

In step S18, the CPU 2 obtains the average number of bid 
tender days at an interval of a predetermined advertising period . 
5 Subsequently, the CPU 2 obtains the average transaction price 
days at an interval of a predetermined advertising period (SI 9) 
interval . The following is the details of steps S18 and S19. 

The CPU 2 creates a second collection table 40 based on 
a predetermined advertising period (e.g. , 10 days, 20 days and 

10 30 days) in the MM 3 . FIG. 12 is an explanatory diagram ohowing 
fe eexample of a second collection table 40. The second 
collection table 40 collects and retains the number of records, 
the number of days and the transaction prices corresponding to 
each e #for the predetermined advertising periods. When the 

15 second collection table 4 0 is created, the number of records, 
the number of days and the transaction prices corresponding to 
each of the predetermined advertising periods, are each set to 
zero as an initial value (see FIG. 12) . 

The CPU 2 , whcn When creating the second collection table 

20 40, with respect to a certain first extraction record, the CPU 
2_increments [the number of records] in the second collection 
table 40 by "1" ("1" is added to the number of records) , which 
corrcopondo corresponding to the advertising period containing 
the number of days obtained by subtracting the advertisement 

25 starting date from the transaction date. Subsequently, the CPU 
2 subtracts the advertisement starting date from the transaction 
date in the first extraction record, and adds a value of this 
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subtracted result to [the number of days] corresponding to the 
relevant advert ing advertising period. Further, the CPU 2 adds 
the transaction price in the first extraction record to [the 
price] corresponding to the relevant advertising period. The 
5 CPU 2 executes the processes given above with respect to all 
the first extraction records. 

Thereafter, the CPU 2, when finishing the above processes 
for all the first extraction records, divides a value of each 
[number of days] and a value of each [price] retained in the 
10 second collection table 40 by [the number of records] 

corresponding thereto . Thus , the CPU 2 obtains an average value 
(an average number of bid tender days) of [the number of days] , 
and also an average value (an average transaction price) of the 
[price] . 

15 Thereafter, the CPU 2 creates a message containing the 

average number of bid tender days and the average transaction 
price that have thus been obtained, and transmits this message 
to the relevant client C (step S20) . After this process, the 
CPU 2 loops the processing back to step SI. 

20 The client C, when When receiving the message delivered 

from the server S, the client C displays the received message 
on the display device 19 . FIG. 13 is a diagram ohowing a dioplay an 
example of a message 41 displayed to the sales applicant, which 
corrcoponda corresponding to the processes in steps S18 and S19 . 

25 The component sales applicant (the user of the client C) is thus 
provided with the using condition corresponding to the quality 
information on the oalco transaction target article ( vehicle 
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component^ as the support information for setting the sales price . 
The user of the client C is also provided with the average number 
of bid tender days and the average transaction price at feke 
interval of the predetermined advertising period interval . 

Note that the first embodiment has given the example in 
which the predetermined advertising period is set to less than 
10 days, 11 -20 days, 21 -30 days, and 31 days or longer , however, 
a length of the advertising period may adequately set to any 
desired value . 

<0peration in First Embodiment> 

According to the first embodiment , if the user of the client 
C wishes to sell the a vehicle component via the bulletin board 
1, the client C givco the ocrvcr S the requcat for thc requests 
support information for setting the price of the vehicle 
component from the server S . The client C is given the input 
screen 31 for the ocrvcr G to input the information (the 
information for identifying the transaction target, and the 
quality evaluation information) needed for providing the support 
information . 

Then, the client C supplies the server S with the 
identifying information (the image and the component number) 
of the transaction target article (vehicle component), the 
quality evaluation information (the using period) e-f -for this 
component and the desired sales price via the input screen 31. 
Then, the server S evaluates the quality (the using condition) 
of the component on the basis of the identifying information 
of the component and the quality evaluation information (the 
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using period) (step Sll) . 

Subsequently, the server S obtains the average number of 
bid tender days in the price range embracing the desired sales 
price by uoc of , using the respective items of information 
5 received from the client C and the transaction achievement 
information (the records in the transaction history DB 24) of 
the sales conducted via the bulletin board 1 (step S13) . Then, 
the server S supplies the client C with the using condition and 
the average number of bid tender days as the support information 
10 (step S14) . 

The support information is displayed on the display device 
19 of the client C. The user (the sales applicant) of the client 
C is able to know provided the quality of the sales target component 
and aloo to know from the average number of bid tender days Jhow 
15 long it takco a time to catch thc took to find a purchaser e# 
for the relevant component at the desired sales price K 

Moreover, the server S obtains the average number of bid 
tender days and the average transaction price for every price 
range with respect to the galea transaction target component 
20 article (steps S15 and S16) , and supplies thcoc pieces of this 
data to the client C (step S17) . The sales applicant is thereby 
able to know how ooon the purchaser will be found out by rccogni zing 
able to determine which price range is proper for the sales 
transaction target componcnt art icle and how soon a purchaser 
25 will be located in that price range . 

Further, the server S obtains the average number of bid 
tender days and the average transaction price at the interval 
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e-£ predetermined advertising period intervals with respect to 
the oalco transaction target component article (steps S18 and 

519) , and supplies thcoc piccco of this data to the client C (step 

520) . With this operation, the sales applicant io able to know 
5 a rclation can determine the relationship between the length of 

the advertising period and the transaction price with respect 
tefor the galea transaction target componcnt art icle . 

As discussed above, the sales applicant can receive the 
quality inf ormat ione#- f or the sales transaction target component 

10 article by receiving the information about the using condition 
information as the support information, and can utilize these 
pieces of information as a-key for factors in setting the pricco 
price of the vehicle component concerned. Further, the sales 
applicant receives the information on the transaction 

15 achievements (the average number of bid tender days and the 
average transact ion price as statistic values) withrcopect to for 
the component the user wants to sell and the component of which , 
by the component number and the using condition arc the same 
(the identifying information and the quality information are 

20 the same) as the support information. The sales applicant is 
thereby capable of predicting how soon the purchaser can be found 
al located by knowing how much the affect of the price e^-set 
for the oalca transaction target component — io oet article . 

Accordingly, the sales applicant is capable of setting 

25 the desired sale price of the sales target component to a price 
that leads to a desirable result (such as being sold higher and 
sooner) to the sales applicant. Namely, the sales applicant 
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is able to properly set the price. The administrator of the 
bulletin board 1 is capable of increasing the number of users 
of the bulletin board 1 and of improving the profits , in the 
case of collecting the fee for using the bulletin board 1 from 
the user thereof-? — improving the profito . 

Incidentally, the contrivance in the first embodimentHre 
that ^ the processing rcault results in step S13, the processing 
rcaulta in steps S15 and S16 and the proccooing rcoulto in steps 

518 and S19, are individually transmitted to the client C. 
Alternately, the server S may , however, transmit to the client 
€ one message into to the client C which the includes messages 
3 7 , 3 9 and 41 are integrated juot when finishing the process 
in step S19. 

Further, in the first embodiment, the process in step S13 , 
the processes in steps S15, S16 and the processes in steps S18, 

519 are described being executed in series to the af ter receiving 
a request for providing one item of support information. The 
client C may, however, request only any one of the processes 
described above . 

Moreover, the process in step S13, the processes in steps 
S15, S16 and the processes in steps S18 , SI 9 may take any sequence . 
Further, the process in step S15 and the process in step S16 
may be reversed in order, and the process in step SI 8 and the 
process in step S19 may also be reversed in order. 

Furthermore, the first embodiment taken ouch a mode 
tfeatdescribes the server S provided as providing the support 
information to the client C. However, the external storage 
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device 14 of the client C io otorcdwith can store the same content 
go what inf ormation as is stored in the external storage device 
4, and the support request io inputted from input via the KBD 

2 0 or the PD 21-? — in which caoc may be answered by the CPU 12 
5 of the client C , which may execute the processes shown in FIGS. 

3 and 4, and the messages 37, 39, 41 may be displayed on the 
display device 19. Namely, the present invention may be 
actualized by contained with a stand-alone computer. This is 
the same with second and third embodiments. 

10 [Second Embodiment] 

Next, a second embodiment of the present invention will 
be discussed. The second embodiment hao the pointo common 
fe ocontains aspects and features similar to the first embodiment . 
Hence, the discussion will concentrate on different pointo 
15 differences therebetween . 

The processes of the server S and the client C in the second 
embodiment are the same as those in the first embodiment^ as 
far as the steps SI ~ S5 shown in FIG. 3 are concerned. In the 
second embodiment, however, an input screen transmitted to the 
20 client C from the CPU in step S6 is different from the input 
screen in the first embodiment. 

FIG. 19 is a process flowchart ohowing the proccooco of for 
the servers (the processes of the CPU 2 ) in the second embodiment . 
In the second embodiment, the CPU 2 transmits dioplay data on 
25 eft-input screen 31A in place of the input screen 31 to the client 
C in step S106 corresponding to step S6 , as shown in FIG. 21 . 

FIG. 14 is a diagram ohowing a dioplay example o n an example 
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of the input screen 31A in the second embodiment. As shown in 
FIG. 14, the input screen 31A is different from the input screen 

(see FIG. 5) in tcrmo of the following point . That is, thc that 

input screen 31A does not include the using period entry box 
5 34 and is provided with input screen 31A substitutes a [Next] 
button go a oubotitutc 43 for the transmission button 36. 

When the client C receives the display data on the input 
screen 3 1A and displays the input screen 31A on the display device 
19, the user of the client C inputs an image^ a component number 

10 and a desired price by the same method as that used in the first 
embodiment. Then, the [Next] button 43 is depressed by 
manipulating the KBD 20 or the PD 21. 

Then, the CPU 12 of the client C transmits, to the server 
S, a request for being given the display data on a second input 

15 screen 44 (see FIG. 16) which contain at least a component number 
of the sales transaction target vehicle componcnt article . The 
Upon receiving this request (step S107; Y) , the CPU 2 of the 
server S- — upon receiving this request — (step S107; — — refers 
accesses the component database DB 2 3 and reads from the 

20 component DB 23a component code corresponding to the component 
number received from the client C into the MM 3 (step S108) . 

Next, the CPU 2 refers to the assessment item database 
DB 2 6 stored in the external storage device 4 and corresponding 
to the component code read into the MM 3, and reads assessment 

25 check items into the MM 3 corresponding to the component code 
read into the MM 3 , thereby creating display data (based on an 
HTML format etc) on the second input screen 33 (step S109) . 
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FIG . 15 is a diagram ohowing an example of a data structure 
of the assessment item DB 26 shown in FIG. 2. The assessment 
item DB 26 is provided for, e.g., every component code. The 
assessment itemDB 2 6 retains information on the assessment items 
5 of an Qoocoomcnt targct a component and scores (points) 

corresponding to answers to questions about the assessment items 
in a structure suited to a layout on the second input screen 
44. In the example shown in FIG. 15, the assessment items in 
the assessment item DB 26 are a using period, cleaning of O 
10 O portion, polishing of OO portion, rust, scraped flaw, 
scratches and a recess. 

The CPU 2 , whcn When creating the display data on the second 
input screen 44, the CPU 2 transmits the display data to the 
client C (step S110) . The client C, — upon Upon receiving the 
15 display data, the client C displays the second input screen 44 
based on the display data on the display device 19. 

FIG. 16 is a diagram ohowing a diaplay an example on of 
the second input screen 44. Referring to FIG. 16, the second 
input screen 44 includes the using period entry box 34 , an answer 
20 box 44a to the questions about the assessment items retained 
in the assessment item DB 26, and the send button 36. Plural 
concepts of answers to the questions about the assessment items 
are displayed in the answer box 44a, and a check box containing 
check circles for indicating the respective answers is provided. 
25 The user of the client C enters the using period in the 

entry box 34 and checks the check circle corresponding to the 
answer in the check box with roopcot corresponding to the question 
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about each assessment item, thereby answering the question. 
Then, when finishing picking up the anowcra to answering all the 
questions, the user depresses the send button 36. 

Then, the CPU 12 of the client C transmits, to the server 
S, the image, the component number and the desired sales price 
that have been inputted input on the input screen 31A, and the 
answers to the questions about the using period and other 
assessment items that have been inputted input on the second 
input screen 44 . 

The CPU 12 of the acrvcr S, — whcn A fter receiving the 
respective pieces of information via the communication interface 
I/F 5 (step Sill) , as in the first embodiment, judges the CPU 
12 of the server S determines whether or not the using period 
exceeds the using limit (step S112) . If over the using limit 
(step S112; Y) , the error process (step S113; the same as step 
S10) previously described above is executed. 

Whcrcao if lf the using period does not exceed the using 
limit (which does not correspond to the using condition C) (step 
S112; N) , the CPU 2 refers again to the assessment item DB 26 
used for creating the display data on the second input screen 
44, and calculates assessment scores (points) in accordance with 
based on the answers to the questions, which have been received 
from the client C (step S114) . For inotancc example , the CPU 
2 sets a base of the assessment score to 100 , and adds or subtracts 
a score corresponding to the answer to the question to or from 
the base score 100. 

Next, the CPU 2 obtains an assessment rank by use of using 
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the calculated result of the assessment score (step S115) . That 
is, the CPU 2 refers to the assessment rank table 27 stored in 
the external storage device 4 and reads therefrom the assessment 
rank corresponding to the calculated result into the MM 3 . 
5 FIG. 17 is an explanatory diagram ohowing thc example of 

an assessment rank table 27 shown in FIG. 2. As shown in FIG. 
17, the assessment rank table 27 is stored with ranges of the 
assessment scores (points) and the assessment ranks that 
correspond to each othcr range . Note that the assessment rank 

10 is set in five categories A2 , Al , B2 , Bl and C in this example, 
however, the (number of) categories of the assessment ranks may 
be adequately set as needed . 

Next, the CPU 2 obtains the average number of bid tender 
days and the average transaction price by uoc of using the 

15 assessment rank acquired (step S116) . To be specific, the CPU 
2 extracts (reads into the MM 3) all the records ao the third 
extraction rccordo having the component number received from 
the client C and the assessment rank acquired as third extraction 
records . 

20 Subsequently, with rcopect to from the extracted third 

extraction records, the CPU 2 obtains the average number of bid 
tender days and the average transaction price per price range 
by uoc of using the price range table 25 and the first collection 
table 38 by- and the same method as steps S15 and S16 in the first 

25 embodiment . 

Thereafter, the CPU 2 creates a message containing the 
acquired assessment rank, the assessment score, the average 
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number of bid tender days and the average transaction price per 
price range, and delivers this message to the relevant client 
C (step S117) . 

The client C thereby receives the — same mcaaagc, — and 
5 displays this message io dioplaycd on the display device 19. 
FIG. 18 is a diagram ohowing a diaplay an example of a message 
46 displayed on the display device 19. As shown in FIG. 18, 
the assessment score and the assessment rank of the aalco 
transaction target component article are displayed to the user 

10 (sales applicant) of the client C. Further, the average number 
of bid tender days (the average advertising period) and the 
average transaction prices for every price range with respect 
to the vehicle componento transact ion target article having the 
above assessment rank and the same component number, are also 

15 displayed to the user. 

Note that the average number of bid tender days in the 
price range inclusive of the desired sales price may be obtained 
based on the assessment rank by substantially the same method 
as step S13 in the first embodiment, then transmitted to the 

20 client C and displayed on the display device 19 (the average 
number of bid tender days may be provided as the support 
information to the sales applicant) also in the second embodiment . 

Further, the average number of bid tender days and the 
average transaction price at the interval of the predetermined 

25 advertising period interval may be obtained based on the 
assessment rank using the second collection table 40 by 
substantially the same method as steps S18 and S19 in the first 
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embodiment, and then transmitted to the client C and displayed 
on the display device 19 also in the second embodiment. 

In accordance with the second embodiment also, the sales 
applicant is able to set a proper price oj— f or the transaction 
5 target component article with reference to the support 

information (the assessment rank, the average number of bid 
tender days and the average transaction price) . Further, in 
the second embodiment, the quality of the component is evaluated 
basedon the plurality of assessment items (assessment standards) 

10 including the using period. Thus, in the second embodiment, 
the quality of the oalcs transaction target component article 
is examined in greater details than in the first embodiment, 
and hence a gap between the condition of the galea transaction 
target component article and the transaction price can be made 

15 smaller than in the first embodiment. 

Note that while the assessment rank is defined as one field 
of the record in the transaction history database DB 24, in the 
second embodiment of the present invention, the assessment item 
database DB 26 and the assessment rank table 27 , take use database 

20 structures uocd in the transaction system according to the second 
embodiment but that are not used in the first embodiment . 
Therefore, if embodied in the tranaaction oyatem according to in 
the first embodiment, the assessment ranks in the transaction 
history DB 24, the assessment item DB 26 and the assessment rank 

25 table 2 7 are unnecessary. 

Furthermore, according to the second embodiment, the 
assessments about the rust, scraped flaw, scratches and rcccoo 
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recesses are made based on the answers of the sales applicant. 
Inatcad of thia modc Al ternatively , these assessment items are 
removed from the assessment item DB 26 and the second input screen 
44 as well , and , ao a aubot itutc for uoing thc o c aaocaomcnt itcmo , 
5 the assessment score (points) may be calculated by uoc of using 
the vehicle component image received via the second input screen 
44. In this caso embodiment , the component image is displayed 
on the display device 19, then and the operator of the server 
S may input a score corresponding to a result of the assessment 
10 to the acrvcr S, — and or the CPU 2 may execute a predetermined 
process of the image in the server S, whereby the assessment 
score can be automatically calculated. 
[Third Embodiment] 

Next, a third embodiment of the present invention will 
15 be discussed. The third embodiment has pointo common contains 
aspects and features similar to the first embodiment, and the 
discussion will therefore be focused on different point 3 the 
differences from the first embodiment. 

FIG. 2 0 is a flowchart showing processes (of the CPU 2) 
20 of the server S in the third embodiment. The processes of the 
server S and the client C in the third embodiment are the same 
as those in the first embodiment as far as steps SI - S5 shown 
in FIG. 3 are concerned. In the third embodiment, however, an 
input screen transmitted to the client C in step S6 is different 
25 from the input screen in the first embodiment . 

In accordance with the third embodiment, in the client 
C, a type and a frame number of the vehicle from which the Galea 
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transaction target component article is taken, are inputted 
^e input on the input screen. Therefore , — inln the third 
embodiment, the dioplay data on an— input screen 3 IB arc is 
transmitted to the client C in step 3206^ corresponding to step 
5 S6. 

FIG. 21 is a diagram ohowing a dioplay an example on of 
the input screen 3 IB in the third embodiment. As shown in FIG. 
21, the input screen 3 IB is different from the input screen 31 
(see FIG. 5) in tcrmo of the following points. To be specific, 

10 the input screen 3 IB io what a that vehicle type entry box 4 8 
and a frame number input box 4 9 are added to the configuration 
of the input screen 31 . 

When the client C receives the dioplay data on the input 
screen 3 IB and displays the input screen 31B on the display device 

15 19, the user of the client C inputs an image, a component number 
and a desired price by the same method as the first embodiment. 
At this time, the user is also able to selectively input data 
for either the using period and a couple of^ the vehicle type 
and the frame number . 

20 Namely, the input screen 3 IB is contrived configured so 

that if one of either the using period and the couple of or the 
vehicle type and the frame number is inputtcd are input , the other 
can not be inputtcd input . Then, if lf neither the using period 
nor the couple of the vehicle type and the frame number io inputted, 

25 a contrivance io that are input, input screen 31b is configured 
such that the data can not be transmitted to the server S even 
when depressing the send button 36. 
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The uocr, — whcn When finishing the data entry process on 
the input screen 3 IB, the user depresses the send button 3 6 by 
manipulating the KBD 20 or the PD 21. Then, — feteThe CPU 12 of 
the client C transmits the image, the component number, the 
5 desired price and the using period (or the vehicle type and the 
frame number) to the server S. 

The CPU 2 of the ocrver S, when When receiving the above 
information from the client C (step S2 07) , the CPU 2 of the server 
S determines j udgca whether or not the information received 

10 contains the vehicle type and the frame number of the vehicle 
(step S208) . At this time, if containing the received data 
contains the vehicle type and the frame number (step S208; YES) 
the CPU 2 advances the processing to S209. Whereas Conversely, 
if the vehicle type and the frame number are not contained (step 

15 S2 08; NO) in the received data , the CPU 2 judgco determines that 
the information received from the client C containo not does not 
contain the vehicle type and the frame number but the using period, 
and diverts the processing to step S8 in FIG. 3 . The proccoaeo 
after thio arc A fter diverting to step SB, the subsequent 

20 processing is the same as those in discussed under the first 
embodiment . 

When the processing proceeds to step S2 09, the CPU 2 
searches the vehicle database DB 29 stored in the external storage 
device 4 by use of using the vehicle type and the frame number, 
25 and thus judgco determines whether or not a record containing 
the vehicle type and the frame number is stored therein. 

FIG. 22 is an explanatory diagram ahowing example of the 
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vehicle DB 2 9 shown in FIG. 2. As shown in FIG. 22, the vehicle 
DB 29 retains records each consisting of fields such as a vehicle 
type, a frame number and an operation starting date. 

The CPU 2 i if If a record containing the type and the frame 
number does not exist in the vehicle DB 29 (step S209 ; NO) , judge 3 
the CPU 2 determines that the information received from the client 
C contains the using period, and diverts the processing to S8 
in FIG. 3 . The- After diverting to S8, the subsequent processes 
thereafter are the same as thoac in discussed under the first 
embodiment . Whcrcao if thc lf a record containing the vehicle 
type and the frame number exists in the vehicle DB 29 (step S209; 
YES) , the CPU 2 reads the relevant record from the vehicle DB 
2 9 into the MM 3 . 

Next, the CPU 2 obtains a component code corresponding 
to the component number received from the client C (step S211) . 
This process is executed in such a way that the CPU 2 searches 
an unillustrated component number/component code conversion 
table stored beforehand I in the external storage device 4 by 
ua cof use of the component number. Note that the CPU 2 may also 
obtain the component code by searching the component database 
DB 23 . 

Next, the CPU 2 judgco determines whether or not a record 
containing the component code, the vehicle type and the frame 
number is stored in the maintenance/repair history database DB 
28 stored in the external storage device 4 (step S212) . 

FIG. 23 is an explanatory diagram example of the 
maintenance/repair history DB 28 shown in FIG. 2. The 
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maintenance/repair history DB 28 retains a single or plurality 
of records each consisting of fields such as a vehicle type, 
a frame number, a work date, a component code and a work 
classification. The work classification field takes a value 
5 of any one of [exchange] , [cleaning] , [plate working] and 
[coating] in accordance with the type of the maintenance or the 
repair (restoration) . 

The CPU 2 , if I f the record containing the component code, 
t ^ le vehicle type and the frame number is not stored in the 
10 maintenance/repair history DB 28 (step S212; NO), The CPU 2 
advances the processing to step S217. If a record is stored 
therein (stepS212; YES) , the CPU 2 make a advances the processing 
proceed to step S213 , and reads that record into the main memory 
MM 3 . 

15 Subsequently, the CPU 2 judgca determines whether or not 

the work classification in the record read into the MM 3 is 
[exchange] (step S214) . If the work classification is 
[exchange] , the processing proceeds to step S216. Whcrcao if 
fiefe- If the work classification is not [exchange] , the processing 

20 goes forward to step S217 S215 . 

In step S215, the CPU 2 judgco determines whether or not 
the work classification in the record in the maintenance/repair 
history DB 28 that has been read into the MM3 is [cleaning] . 
If the workclassif icationis [cleaning] , the processingproceeds 

25 to step S216. Whcrcao if not If the work classification is not 
[cleaning] , the processing diverts to step S217. 

In step S216, the CPU 2 obtains, as the using period, a 
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period extending from [work date] in the record in the 
maintenance/repair history DB 28 that has been read into the 
MM 3 up to the present time. Thereafter, the CPU 2 loops the 
processing back to step S8 in FIG. 3, and executes the same 
processes as those in the first embodiment. 

In step S217, the CPU 2 obtains, as the using period, a 
period extending from [operation starting date] in the record 
in the vehicle DB 29 that has been read into the MM 3 in step 
S210 up to the present time, and loops the processing back to 
step S8 . Thereafter, the CPU 2 executes the same processes as 
those .in the first embodiment. 

According to the third embodiment, the oalco transaction 
target component articles of the sales applicant is removed from 
the vehicle, and the same component is fitted to the vehicle 
in a maintenance and repair shop related to the administrator 
of the bulletin board 1, in which case the type and the frame 
number of the vehicle are entered on the input screen 31b instead 
of the using period, and the using period is automatically set 
based on these pieces of data. Accordingly, under above 
conditions, even if the sales applicant forgets the using period 
of the component, the using condition of the component can be 
determined based on the precise using period. 

Note that the maintenance/repair history DB 28 , the vehicle 
DB 2 9 shown in FIG. 2, the component number/ component code 
conversion table (not shown) and the input screen 3 IB, are used 
in only the third embodiment and may not be therefore provided 
if the transaction system in the first embodiment is carried 
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out. Further, the first through third embodiments may be 
properly combined within the scope of the present invention 
without departing from the purpose of the present invention. 
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